Many diagnostic tools, such as used to analyze operation of motor vehicles or the like, provide continuous read-out of one or more measured parameters, now typically shown as text or graphical displays. Examples of computerized diagnostic systems for automotive applications are disclosed in U.S. Pat. No. 6,285,932 to de Bellefeuille et al. and U.S. Pat. No. 6,405,111 to Rogers et al.
As the sophistication of such tools has increased, the diagnostic tools have provided more and more data output to the user. Where the apparatus or system under test is running during the test, the tool often provides a concurrent real-time display for the user to view. The diagnostic tool may perform measurements (e.g. in a manner similar to a volt-ohm meter) and/or receive measurement information from remote sensor devices, for example by scanning on-board sensors incorporated into a vehicle by its manufacturer and/or through data acquisition from a vehicle's on-board diagnostic system via a specific diagnostic connector designed for that purpose by the manufacturer. The display shows changing information from the running measurements by the diagnostic tool and/or from the on-board sensors. Where the advanced tool processes many parameters concurrently, the diagnostic tool provides ongoing real-time output of the measured values of numerous parameters. For example, a display screen of an engine analyzer might provide concurrent running text and/or graphical display of six or eight engine parameters or more. In a graphic output example, the tool might concurrently show six or eight waveform plots on a display screen, like parallel plots on a scope.
In operation, a user has been required to remain near the display and monitor the displayed output(s) during the test. For an engine analyzer application, it has been proposed that the system have an associated portable display and control unit, to allow the technician to move about the vehicle during the test yet still observe the displayed parameters on the portable device (see e.g. U.S. Pat. No. 6,227,043 to Schoenbeck et al.). Although this may provide the user some degree of freedom, the user must still observe the display during the ongoing test, which may not always be convenient.
Some users of diagnostic tools can not safely observe the display during a test. For example, if the tool is incorporated into or connected to a vehicle and operated while a person is driving the vehicle, for test purposes, the driver must concentrate on driving the vehicle and can not pay close attention to the display throughout the test drive. Clearly a need exists for a technique to operate a diagnostic tool that provides real-time display(s) but does not require constant monitoring.
As an initial answer to this need, Snap-on has offered one or more diagnostic tools with a number of “trigger” modes in which the tool will capture and store data for the measured parameters for later display, in response to occurrence of certain pre-defined trigger events. The data stored for later review may correspond to the moment in time when the tool detects the trigger. Some of the Snap-on tools take a snap shot of the measured data parameters, in response to activation of the “trigger” function. The “snap shot” actually involved capture and buffering of running parameter data for some period of time, such that the storage of buffered data upon triggering maintains data from the time of the event as well as data from before and/or after the trigger occurs. An option on the trigger menu allowed the user to define the position of the snap shot frames recorded relative to the trigger, i.e. to trigger storage for later review at the beginning, the middle or the end of the buffer range. Once a snap shot has been recorded, it can be reviewed frame by frame, and up to 6 parameters plotted on the display screen in a graphing mode.
In one of the Snap-on products, the available trigger functions include, a Quick trigger, a Manual trigger and an Any Code type trigger. The quick trigger/manual trigger types are accessed from different menus but are otherwise similar. When activated, the Quick trigger immediately starts capturing data for later display; whereas in the Manual trigger type operation, the tool waits for a keypress after which it begins capturing data. In both of these modes, however, the operator manually causes the tool to store captured data for later display.
The Any Code type trigger relates to receipt of special diagnostic codes from the on-board diagnostic system of the vehicle under test. The user, however, has no option to select or control the particular code to look for. Receipt of any of the codes from the vehicle automatically triggers the snap shot recording of data, essentially so the tool records data upon detection of occurrence of any trouble code at all. Another predefined trigger related to engine RPM falling to 300 RPM or less.
In each type trigger operation, the tool stores parameter data, for later review by the user. As a result, the user need not remain present throughout the test. With the Quick trigger or Manual trigger operation, the user can activate the diagnostic tool and leave it to collect the data. With the code-based trigger or the RPM trigger, the user can leave the test vehicle running and the tool operating and look back later (e.g. after a test drive is complete) to observe the data stored upon detection of the trouble code or the low RPM.
However, these options alone are not sufficient for many diagnostic applications. If the event that the user needs to observe does not rise to the level of a “trouble” or result in the low RPM, then the user must observe the test results until he/she sees the desired event or some combination of measured conditions and can manually trigger the data storage. Hence a need still exists for a more convenient technique for controlling or operating a diagnostic tool that provides increased flexibility in providing the user with necessary data while minimizing the amount of direct observance necessary during the test.